- a [[ritual]].
  - part of [[Festivus]].

I love computers and humans, and they come together beautiful in phenomenons like open source, which I love particularly. I am eternally thankful for the *millions* of humans who contribute to free software and make the world a better place.

Having said that, here are some out-of-season [[airing of grievances]] about software, in no particular order:

## [[Flatpak]]

Flatpak sucks, yet is somehow also the best known (to me) solution to the problem of shipping apps in a platform/distribution agnostic way as of the time of writing ([[2023]]). [[Snap]] is clearly worse. How can this be?

Why, WHY, am I able to `flatpak search chromium` and even `flatpak install chromium` but (I kid you not) I need to write `flatpak run org.chromium.Chromium` to actually run the package?

Oh, it's because the developers refuse to accept patches to implement short forms for the run subcommand specifically. In practice this means ~millions of people around the world are maintaining independent collections of shoddy one-liners or aliases to make flatpak command invocations sane again.

Also, if you run `flatpak search` in a narrow terminal it will helpfully elide the full application ID, so flatpak search cannot even be depended on to retrieve the right incantation consistently. WHY.

## [[Systemd]]

I love Systemd; I remember curating SysV Init scripts and I think the process of writing Systemd services is much improved. Having said that :)

Why is it so hard to just make sure a service will actually start and keep retrying forever if it can't start? There are several incantations in the configuration spec that *seem* like they should achieve indefinite retries, but really don't (or do only in some cases). I understand why you'd want to have something like a sane retry policy (with backoff), but I really would like to tell it: just keep trying for me. Under no situation it seems reasonable for me to find a service marked as `inactive (dead)`, run start on it and have it work flawlessly. The computer should have done that for me.

Also, why is it non-trivial to go from operating over a service (with e.g. `systemctl --user status/stop/start foo`) to operating over its logs? For the latter you need (checks notes) `[[journalctl]] --user-unit foo`. Maybe it just took me longer than normal to find this, but it's unclear to me why `systemctl --user logs` doesn't exist, or why it's --user-unit in the case of journalctl instead of --user.